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REMARKS 

Claims 40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 are pending and stand rejected. 
Claims 40-42 and 55-56 are rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 5,243,331 to McCausland et al. ("McCausland") in view of U.S. Patent No. 5,915,209 
to Lawrence ("Lawrence"), U.S. Patent No. 5,809,483 to Broka et al. ("Broka"), U.S. Patent 
No. 5,101,353 to Lupien et al. ("Lupien"), Admitted Prior Art ("APA"), and U.S. Patent No. 
7,080,050 to Himmelstein ("Himmelstein"). Claims 61 and 71 are rejected under 35 U.S.C. § 
103(a) as being unpatentable over McCausland in view of Lawrence, Lupien, and Himmelstein. 
Claims 62-65, 67-69, and 72-75 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
McCausland in view of Lawrence, Lupien, Himmelstein, and U.S. Patent No. 7,231,363 to 
Hughes et al. ("Hughes"). Claims 58 and 59 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of U.S. Patent No. 6,343,278 to Jain et al. ("Jain"), 
Lupien, APA and Himmelstein. 

Upon entry of this paper, claims 40-42, 55, 56, 58, 59, 61-65, 67-69 and 71-75 will be 
pending in the application and are presented for consideration. Applicants hereby amend claims 
40, 58, 61, 68 and 71. These claim amendments do not introduce new matter to the application. 
Support for the claim amendments can be found throughout the specification, including, e.g., at \ 
[0090] of U.S. Published Patent Application No. 2002/0156719 ("Applicants' Specification"). 
The paragraph cited for support is merely an example and the support for the amendments is not 
limited to the cited section. 

I. Rejection of Claims 40-42 and 55-56 under 35 U.S.C. § 103fa^ 

The Office Action rejected claims 40-42 and 55-56 under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of Lawrence, Broka, Lupien, APA, and Himmelstein. 
(Office Action, pp. 3-11.) For a rejection under § 103 to be proper, the references must expressly 
or impliedly suggest the claimed invention taken as a whole. Additionally, the combination must 
not render either reference inoperable. As set forth below, McCausland fails to teach or suggest 
each and every element of claim 40, from which claims 41, 42, 55 and 56 depend. Lawrence, 
Broka, Lupien and Hughes fail to cure the defects of McCausland, and one of ordinary skill in the 
art cannot combine these references to arrive at the steps recited in claim 40. 
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a. McCausland Fails to Teach Each and Every Element of Amended Claim 40 
As an initial matter, the Office Action states that McCausland does not explicitly disclose 
the "receiving... authorization" step, the "transmitting" step, the "enabling... at least one of the 
first and second traders to complete..." step, the "matching" step, and the "preventing" step. 
(Office Action at 5-6.) 

McCausland describes a "computer system and program for trading securities comprising 

a central host computer system, plural personal computer-based trading stations geographically 

remote from the host system, a communications network connecting the trader stations to the 

host system, and a special-function keypad attached to the trading station for interacting with the 

system." (McCausland at 2:40-47.) McCausland describes order entry and execution as follows: 

All orders in the trading system 1 0 arc limit orders as that term is 
understood in the art and are "live" until canceled. The system 
accepts one bid and one offer per issue for that trader, and any 
change in market price or size cancels the previous order. 



To enter an order (Bid or Offer) or execute an order (Hit or Take). 
a trader follows the following steps. First, the trader highlights the 
desired issue. Second, the trader presses one of the action keys 226, 
228, 230 or 232: BID, OFFER, HIT or TAKE. The selected action 
is displayed on the Action Line. To change the size or value of the 
requested transaction, the trader can type a size next to the action if 
desired, or keep the default. The [Enter] key is then pressed. The 
order for the issue selected is displayed in a small window on the 
trader's page. To change a price, the trader can tick the price up 
and down by pressing [f] or [J,] while the issue is in the window, 
until the desired level is reached. Long Hand Order Entry may also 
be accomplished. Finally, the trader presses [Con firm] to complete 
the order or press [Reject] to cancel the order. 

Id. at 22:40 - 23:29 (emphasis added). 

In contrast to McCausland's manual order entry and execution technique, Applicants' 
claim 40 recites "preventing, by the electronic trading system, a match of the received trading 



orders based on the predetennined order conditions associated with the match, the preventing 
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step resulting in a zero bid-ask spread that locks a market for the bond instrument or a negative 

bid-ask spread that crosses a market for the bond instrument." 

As set forth in Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result. 

(Applicants' Specification at [0090].) McCausland does not teach or suggest preventing a match 
of trading orders resulting in a zero bid-ask spread that locks a market for the bond instrument or 
a negative bid-ask spread that crosses a market for the bond instrument. Instead, McCausland 
merely describes use of a keypad by a trader to accept bids or offers, thereby executing an order. 

In addition, Applicants submit that McCausland fails to teach or suggest the step of 
"receiving, by the electronic trading system, a subsequent trading order having a more favorable 
price than at least one of the orders involved in the preventing step, the subsequent trading order 
resulting in a positive bid-ask spread that unlocks or uncrosses the market." As set forth above, 
McCausland merely accepts bid or offers and executes orders. McCausland does not disclose 
receipt of subsequent orders that result in a positive bid-ask spread that unlocks or uncrosses the 
market. 

The Office Action states that: 

one skill in the art (practitioners such as brokers, market makers, 
dealer, etc) knows that in order to buy or sell securities (such as: 
stocks, bonds, etc,) there have to be at least two counter parties to 
do the trade (a seller and a buyer or a party/counterparty) with and 
in order for the dealer to trade with counterparty, he/she should 
have received from broker/customer and buy-order (bid side) or a 
sell-order (ask or offer side) to trade and then the buy-order or sell- 
order is to be distributed or be displayed/shown to the other 
dealers/traders who may be interested to trade and after a 
negotiation/acceptance the trade has to be executed and the trade is 
completed (APA). 

(Office Action at 6.) However, Applicants respectfully submit that this statement does not read 



on each and every element of the "preventing" and "receiving... a subsequent trading order" steps 
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recited in claim 40. Applicants respectfully request further explanation or citation to references 
which disclose the elements of claim 40. 

Further, the Office Action states that the "preventing" step "is designers choice how does 
he/she filters/search it order for matching." (Office Action at 7.) However, Applicants 
respectfully submit that the "preventing" and "receiving... a subsequent trading order" steps 
recited in claim 40 result in specific order and market conditions that must be addressed, and are 
more than simply a choice on filtering or searching for matches. 

b. Broka Fails to Remedy the Deficiencies of McCausland 

As discussed above, McCausland fails to teach or suggest each and every element of claim 
40. Broka fails to cure the defects of McCausland, at least because Broka fails to teach or 
suggest "preventing, by the electronic trading system, a match of the received trading orders 
based on the predetermined order conditions associated with the match, the preventing step 
resulting in a zero bid-ask spread that locks a market for the bond instrument or a negative bid- 
ask spread that crosses a market for the bond instrument," or "receiving, by the electronic trading 
system, a subsequent trading order having a more favorable price than at least one of the orders 
involved in the preventing step, the subsequent trading order resulting in a positive bid-ask spread 
that unlocks or uncrosses the market," as recited in claim 40. 

Broka relates to "[a] system for monitoring information about debt securities and 
reporting trades in the debt securities market." (Broka at Abstract.) Specifically, Broka describes 
a "regulated, computerized bond trading system has been developed to gather quote and trade 
information from several bond traders and other users, and to organize and disseminate such 
information quickly and reliably." Id. at 1:55-60 (emphasis added). 

Broka's system provides five main functions, described as follows: 

Trade management is mainly concerned with reporting trades . A 
trade report occurs when users enter bond trade information into 
the FIPS system . FIPS' basic trade reporting functions include 
entering a trade report, modifying a trade report, and disseminating 
a report. Other functions include browsing, statistics gathering, and 
summary updating. 
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Quote management is mainly concerned with updating bid and ask 
prices . A quote in FIPS occurs when a user enters a bid and/or 
offer for a particular bond into FIPS . FIPS' quote management 
functions include entering, modifying, withdrawing, restoring, and 
removing quotes. Additional quote management functions include 
monitoring quote activity, disseminating quote data, and setting 
market alerts. 

Market management allows a user to form groups of speci fic bond 
issues , which then become the user's "markets," and to monitor 
bond information changes directly in the group. Such groups are 
referred to as "Minder" groups. 

Directory services allow users to search databases using di fferent 
criteria . Two such databases are bond issue and FIPS participant. 
For example, a user can browse the bond database to find issues for 
which the user has made quotes or to find issues of a given coupon 
rate and maturity year. A user can browse the FIPS participant 
database to list brokers, dealers, or view-only users. 

FIPS utilities allowing users to customize certain interfaces and 
data pres entation formats . For example, user may select certain 
issues to be grouped into "Minder" groups. 



Id. at 5:39-67 (emphasis added). The Office Action alleges that Broka discloses the "enabling" 
step, but does not allege that Broka discloses the "receiving... authorization" step, the 
"transmitting" step, the "matching" step or the "preventing" step. (Office Action at 7-8.) 

As set forth above, Broka is directed toward a system for gathering trade and quote data 
entered by users, and making that data available to the users via reports and databases. Broka 
simply fails to teach or suggest at least the "receiving... authorization" step, the "transmitting" 
step, the "matching" step, the "preventing" step, and the "receiving... a subsequent trading order" 
step as recited in claim 40. 

c. Lawrence Fails to Remedy the De ficiencies of McCausland and Broka 

As discussed above, the combination of McCausland and Broka fails to teach, suggest, or 
render obvious each and every element of claim 40. Lawrence fails to cure the defects of 
McCausland and Broka. 
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Lawrence relates to "a computerized municipal bond trading system having the capability 

to conduct a private electronic auction of bid wanteds between a central market-maker and 

multiple remote clients who are prospective bidders." (Lawrence at 3:36-40.) Lawrence 

specifically describes the trading system as follows: 

A selling trader 14, who may be an owning institution or individual 
but is preferably an SEC-registered securities broker dealer, 
transmits one or more job lots 16 of bonds for sale to the municipal 
bond trading system 10 maintained by a broker, who functions as a 
"market-maker," at any time convenient to the selling trader 14. 
Transmission of job lots 16 to the municipal bond trading system 10 
can be accomplished in any conventional manner; written, faxed, 
telephoned, or the equivalent, but is preferably electronically 
effected in a file that can be directly processed by the municipal 
bond trading system 10, for example, via confidential e-mail, as are 
communications from the market-maker to the seller, over data 
lines 15. Most preferably, the seller is computer- linked to the 
municipal bond trading system 10 on a LAN or a WAN. 

After appropriate central processing employing the municipal bond 
trading system 10, bid wanteds are circulated to buying traders 12 
in order to solicit bids 18. These functions are described in greater 
detail herein below. Bids 18 are received from one or more buying 
traders 12 and transmitted to the seller by any suitable means, such 
as fax or computer network, as described above, for further 
processing. If the selling trader 14 accepts the bid 18. the brokers' 
broker marks the lot "for sale" and completes the execution, 
preferably with the assistance of the municipal bond trading 
s ystem 10, and then transmits customary bu y and sell tickets 20 to 
the selling trader 14 for their internal processing. 

Id. at 6:6-32 (emphasis added). The Office Action alleges that Lawrence discloses the 
"authorizing" and "transmitting" steps of claim 40, but does not allege that Lawrence discloses 
the "matching" step or the "preventing" step. (Office Action at 8-9.) 

As set forth above, Lawrence is directed to a system for facilitating bids and execution of 
trades for municipal bonds. Lawrence simply fails to teach or suggest the "matching," 
"preventing," and "receiving... a subsequent trading order" steps as recited in claim 40. 



d. Himmelstein Fails to Remedy the Deficiencies of McCausland. Broka. and 
Lawrence 
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As discussed above, the combination of McCausland, Broka, and Lawrence fails to teach, 
suggest, or render obvious each and every element of claim 40. Himmelstein fails to cure the 
defects of McCausland, Broka, and Lawrence. 

Himmelstein relates to "an electronic bartering system for bartering items or securities." 

(Himmelstein at 2:29-30.) Himmelstein describes its barter order matching process as follows: 

Once the order is submitted by the barterer at step 448 of FIG. 4D, 
the matching engine searches the website database for a barter 
order or in an embodiment where the engine matches multi-order 
barters, multiple barter orders to satisfy the submitted order. If no 
match is found at step 450, the barter matching engine determines 
whether the order should be posted to the database 452 based on 
the timing selected at step 424 of FIG. 4B. If the order should be 
posted, the barter order database module 1 16 posts the order to the 
database. 

After the barterer clicks on the "continue/agree" icon 548, (and 
depending on the timing chosen), the system 100 in accordance 
with FIG. 4D posts the barter as an available transaction 452, 456 
and/or finds and displays "matching" posted barter orders 450, 454 
via the screen display illustrated in FIG. 6. The "matching" in the 
preferred embodiment includes matching the batterer's desired item 
and barter items with the barter and desired items of single or 
multiple combinations of posted barter orders where any matched 
Himmelstein options have overlapping settlement dates. 



If the individual decides that they are willing to barter away some 
or all of their selected portfolio stock/Himmelstein option for one 
or more barter orders listed, they select to do so 458, of FIG. 4D 
(or as long as they have more barter amount available) by simply 
clicking on each order, (i.e. choosing first preference then second 
preference, and so on). Each time an order is chosen, the system 
100 permits/requires the individual to revise their original quantity, 
and value price in the stock/Himmelstein option for which they 
desire to trade away in the barter, thereby requiring the individual 
to accept the prices and the amount of stock/Himmelstein option 
received in return from the barter order that they had selected. 



Id. at 16:13-58. Himmelstein discloses that: 
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Additionally, when a barter order is chosen, the system 100 "locks" 
the barter order, including the price, to the individual for a 
predetermined duration. A display of the time remaining to 
complete the transaction appears in a "time remaining" display box 
626. Should the time expire, the system 100 provides two options: 
1) finalize transaction; 2) or lose transaction in "X" seconds, with 
seconds decrementing on screen. The system 100 may, if desired, 
inform the individual that someone else is looking at the same 
barter order and may inform other users that there are pending 
barter orders which may come available. 

Upon the individual reviewing available barter orders and deciding 
what they want to do, (i.e. accept one or more orders or none), 
they proceed by choosing one of the following four icons 631-634: 
1) clear; 2) change barter order; 3) finalize transaction; and 4) 
finalize transaction but display more barter options. Each option 
leads to the display of additional screens to complete the selected 
task as indicated in FIG. 4E. 

Id. at 17:17-35. Notably, Himmelste in provides that: 

The barter matching engine 118 selectively matches a batterer's 
barter order with posted barter orders in the database 116. Posted 
barter orders "matching" a batterer's order are displayed such that 
the batterer can select a candidate or candidates from the displayed 
listing of matching posted orders. The matching process 
functionally operates as a filter to display posted orders matching a 
selected criteria. Preferably, the filter is set to match the batterer's 
selected item to be acquired with posted orders having the same 
item to be bartered. 

Id. at 6:60 - 7:2. 

As a preliminary consideration, the Office Action provides a number of citations on pages 
8 and 9 that it attributes to Himmelstein. However, Applicants respectfully submit that the 
citations appear to come from U.S. Patent No. 7,231,363 to Hughes et al. Thus, Applicants 
believe that the citations are inapplicable to Himmelstein. In the event that the Examiner 
maintains his rejection using Himmelstein, Applicants respectfully request the inclusion of 
citations that are found in Himmelstein. 



The Office Action alleges that: 
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Hirnmelstein preventing by the electronic trading system a match of 
the received trading orders when the predetermined order 
conditions associated with the match; and matching plurality of 
orders. 



It would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to combine the disclosure of 
McCausland, Broka, Lawrence and Hirnmelstein and provide an 
electronic trading system to poll the pending order list of bids and 
offers and find suitable matched counter orders with predefined 
rules once the matched found the orders are locked for the client to 
review, accept or cancel and does not let another client to send 
order until the first client makes a decision . 

(Office Action at 8-9 (emphasis added).) 

Applicants respectfully submit that Hirnmelstein docs not teach the step of preventing a 
match based on the predetermined order conditions "resulting in a zero bid-ask spread that locks a 
market for the bond instrument or a negative bid-ask spread that crosses a market for the bond 
instrument," as recited in claim 40. 

As set forth above, Hirnmelstein teaches that participants in a bartering transaction are 
tasked to manually "revise their original quantity, and value price in the stock/Himmelstein option 
for which they desire to trade away in the barter, thereby requiring the individual to accept the 
prices and the amount of stock/Himmelstein option received in return from the barter order that 
they had selected." (Id. at 16:52-58.) Based on this disclosure, the individual can set a value 
price to any level that he or she desires. In contrast, claim 40 recites the prevention of order 
matches where such prevention results in a zero bid-ask spread or a negative-bid ask spread. 

In addition, although Hirnmelstein teaches that the system locks orders chosen for 
bartering (id. at 17:17-35), the "locking" of an order in that context (i.e., holding the order 
open for only one barterer for a predetermined period of time) is markedly different than the 
claimed step of preventing a match when the predetermined order conditions "resulting in a zero 
bid-ask spread that locks a market for the bond instrument or a negative bid-ask spread that 
crosses a market for the bond instrument," as claimed by Applicants. Hirnmelstein simply fails to 
teach or suggest the "preventing" step of claim 40. 
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In addition, Applicants submit that Himmelstein fails to teach or suggest the step of 
"receiving, by the electronic trading system, a subsequent trading order having a more favorable 
price than at least one of the orders involved in the preventing step, the subsequent trading order 
resulting in a positive bid-ask spread that unlocks or uncrosses the market." 



e. Lupien Fails to Remedy the Deficiencies of McCausland. Broka, Lawrence, and 
Himmelstein 

As discussed above, the combination of McCausland, Broka, Lawrence, and Himmelstein 
fails to teach, suggest, or render obvious each and every element of claim 40. Lupien fails to cure 
the defects of McCausland, Broka, Lawrence, and Himmelstein. 

Lupien relates to an "automated securities trading and portfolio management system for 

use by investment managers." (Lupien at 2:60-62.) Lupien describes order execution as follows: 

Orders are executed by the system on a price/time priority basis 
within the system in step 44, although orders could also be 
executed on a price/size/time priority basis. All orders generated are 
forwarded to controller CPU 10 which presents them together with 
those from other clients for display to each client or client process 
in a manner discribed [sic] below. If a purchase order matches a 
sale order (in whole or in part) created for another client portfolio 
the controller will match the two and a trade will occur which will 
be reported to the markets as well as to each client's portfolio 
trading algorithm . If orders are not executed within the system, 
control passes to block 46 where controller CPU 1 0 decides, based 
on recent trading history, where and how much of each order to 
place on which external automated market, broker, exchange and/or 
its own network. 

Id. at 1 1 :44-60 (emphasis added). When matching orders, Lupien states that: 

A match occurs when a buy order and a sell order agree on security 
name, price, size and terms of the trade. If a match is detected, both 
the buy and sell sides of the order are at block 84. In the case of 
external auto-traders, acceptance is tentative and becomes final 
only when confirmation from the externa l auto-trader is r eceive d 
by the system. Since external auto-traders must themselves confirm 
a match there will be a limited period of time before acceptance or 
rejection, and, therefore, the tentative acceptance procedure is 
necessary. B y contrast, interna l auto-tra der s a cce pt matches 
immediately in real time without tentative acceptance . If either side 
of the trade rejects the match, the order is reopened at block 86 
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while the order of the rejecting side is newly time-stamped and 
moved to the rear of its price-priority group. The order of the 
accepting side is not requeued. 

Id. at 13:25-41 (emphasis added). Thus, Lupien's matching techniques either require 

confirmation from an external trader before accepting a match or accept matches immediately. 

The Office Action states that Lupien discloses "matching the completed trading orders 

using a price/time priority in combination with at least one of predetermined order conditions 

when presented; presenting [sic] a match responsive to said predetennined order conditions; and 

matching plurality of orders." (Office Action at 9.) However, Applicants submit that Lupien 

does not teach or suggest preventing a match based on predeteirnined order conditions as recited 

in claim 40. Instead, Lupien provides that matches are either (i) tentatively accepted and become 

final only upon external confirmation or (ii) accepted immediately in real time. (Lupien at 13:25- 

41.) 

Indeed, Lupien does not teach or suggest the step of "preventing, by the electronic trading 
system, a match of the received trading orders based on the predetennined order conditions 
associated with the match, the preventing step resulting in a zero bid-ask spread that locks a 
market for the bond instrument or a negative bid-ask spread that crosses a market for the bond 
instrument," as recited in claim 40. 

In addition, Applicants submit that Lupien fails to teach or suggest the step of "receiving, 
by the electronic trading system, a subsequent trading order having a more favorable price than at 
least one of the orders involved in the preventing step, the subsequent trading order resulting in a 
positive bid-ask spread that unlocks or uncrosses the market." 

For at least the reasons set forth above, the combination of cited references McCausland, 
Broka, Lawrence, Himmelstein, and Lupien fails to teach, suggest, or render obvious each and 
every element of Applicants' claim 40. In addition, one of ordinary skill in the art could not 
combine McCausland, Broka, Lawrence, Himmelstein, and Lupien to arrive at the steps recited in 
claim 40. 

Applicants also submit that combination of McCausland, Broka, Lawrence, Himmelstein, 
and Lupien fails to teach, suggest, or render obvious each and every element of claims 41, 42, 55 



Application No. : 1 0/00 1,921 
Filed: November 15, 2001 
Page 26 of 32 

and 56 at least because those claims depend either directly or indirectly from claim 40. Therefore, 
Applicants respectfully request reconsideration and withdrawal of this ground of rejection. 



II. Rejection of Claims 61 and 71 under 35 U.S.C. S 103(a) 

Claims 61 and 71 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 

McCausland in view of Lawrence, Lupien, and Himmelstein. (Office Action at 10-18.) 

Like claim 40, claims 61 and 71 recite: 

preventing, by the electronic trading system, a match of the 
received trading orders based on the predetermined order 
conditions associated with the match, the preventing step resulting 
in a zero bid-ask spread that locks a market for the bond instrument 
or a negative bid-ask spread that crosses a market for the bond 
instrument; and 

receiving, by the electronic trading system, a subsequent trading 
order having a more favorable price than at least one of the orders 
involved in the preventing step, the subsequent trading order 
resulting in a positive bid-ask spread that unlocks or uncrosses the 
market. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" and 
"receiving... a subsequent trading order" steps of claim 40. See Section La, supra. Also, as 
discussed above, Lawrence, Lupien and Himmelstein fail to remedy the deficiencies of 
McCausland with respect to at least the "preventing" and "receiving. . .a subsequent trading order" 
steps of claim 40. See Sections I.c, I.d and I.e, supra. 

In addition, one of ordinary skill in the art could not combine McCausland, Lawrence, 
Lupien, and Himmelstein to arrive at the steps recited in claims 61 and 71, or render the steps in 
claims 61 and 71 obvious. Therefore, Applicants respectfully request reconsideration and 
withdrawal of this ground of rejection. 



III. 



Rejection of Claims 58 and 59 under 35 V,S,C. § 103(a) 
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Claims 58 and 59 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
McCausland in view of U.S. Patent No. 6,343,278 to Jain et al. ("Jain"), Hirnmelstein, APA, and 
Lupien. (Office Action at 18-22.) 

Claim 58 recites: 

preventing, by the electronic trading system, a match of the 
received trading orders based on the predetermined order 
conditions associated with the match, the preventing step resulting 
in a zero bid-ask spread that locks a market for the bond instrument 
or a negative bid-ask spread that crosses a market for the bond 
instrument; and 

receiving, by the electronic trading system, a subsequent trading 
order having a more favorable price than at least one of the orders 
involved in the preventing step, the subsequent trading order 
resulting in a positive bid-ask spread that unlocks or uncrosses the 
market. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" step and the 
"receiving... a subsequent trading order" step of claims 40, 61 and 71. See Sections La, and II, 
supra. Also, as discussed above, Hirnmelstein and Lupien fail to remedy the deficiencies of 
McCausland with respect to at least the "preventing" step of claim 40. See Sections I.d-e and II, 
supra. Jain fails to remedy the deficiencies of McCausland, Hirnmelstein, and Lupien. 

Jain relates to a "computerized trading system for trading financial instruments or other 
commodities between traders at trader terminals, wherein the trading system facilitates manual 
entry and possible revision of a group of related orders for derivatives based on a common 
underlying currency or other commodity." (Jain at 1:66 - 2:4.) Jain describes order matching as 
follows: 

Orders that are compatible are matched by the dealing system. 
Newly submitted bid and buy orders are matched against 
outstanding offer orders. Newly submitted sell and offer orders are 
matched against outstanding bid orders. 

Any order submitted into the system is first matched against all 
existing bids and offers at the maker's Arbitrator. The existing 
orders are consid er ed in price/time o r der in s ear ch of compatible 
orders. If a compatible order is found, the two orders are 
"matche d" and a d e al is initiate d for the amount equal to the 
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minimum o f the two order amounts . The process continues until the 
remaining three-month equivalent amount of the submitted order 
becomes less than the value of the minimum notional amount 
parameter, or until there are no compatible orders. 

Id. at 13:4-7, 18-27 (emphasis added). 

In contrast to Jain's order matching techniques, claim 58 recites "preventing, by the 

electronic trading system, a match of the received trading orders based on the predetermined 

order conditions associated with the match, the preventing step resulting in a zero bid-ask spread 

that locks a market for the bond instrument or a negative bid-ask spread that crosses a market for 

the bond instrument." As set forth in Applicants' disclosure: 

The service matches trading orders according to the following 
rules: All orders are matched in a strict price/time priority. Within 
each price queue, each order has a time priority established by the 
time of entry for the quantity disclosed to other users. Order 
conditions may prevent a match from occurring. In such an event, 
a locked or crossed market may result." 

(Applicants' Specification at [0090].) Jain simply does not teach or suggest preventing a match of 
trading orders based on predetermined order conditions "resulting in a zero bid-ask spread that 
locks a market for the bond instrument or a negative bid-ask spread that crosses a market for the 
bond instrument." Instead, Jain merely performs a compatibility determination between newly 
submitted sell and offer orders against outstanding bid orders, and compatible orders are 
considered in price/time order. 

In addition, Applicants submit that Jain fails to teach or suggest the step of "receiving, by 
the electronic trading system, a subsequent trading order having a more favorable price than at 
least one of the orders involved in the preventing step, the subsequent trading order resulting in a 
positive bid-ask spread that unlocks or uncrosses the market." 

For at least the reasons set forth above, the combination of McCausland, Lupien, 
Himmelstein and Jain fails to teach, suggest, or render obvious each and every element of 
Applicants' claim 58. The combination of McCausland, Lupien, Himmelstein and Jain also fails to 
teach, suggest, or render obvious each and every element of claim 59 because that claim depends 
from claim 58. 



Application No. : 1 0/00 1,921 
Filed: November 15, 2001 
Page 29 of 32 

Also, one of ordinary skill in the art could not combine McCausland, Lupien, Himmelstein 
and Jain to arrive at the steps recited in claim 58. Therefore, Applicants respectfully request 
reconsideration and withdrawal of this ground of rejection. 

IV. Rejection of Claims 62-65. 67-69. and 72-75 under 35 U.S.C. $ 103(a) 

Claims 62-65, 67-69, and 72-75 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over McCausland in view of Lawrence, Lupien, Himmelstein, and Hughes. (Office 
Action at 22-25.) Claims 62-65, 67-69, and 74 depend from claim 61, claim 72 depends from 
claim 40, claim 73 depends from claim 58, and claim 75 depends from claim 71. 

Claims 40, 58, 61 and 71 each recites: 

preventing, by the electronic trading system, a match of the 
received trading orders based on the predetermined order 
conditions associated with the match, the preventing step resulting 
in a zero bid-ask spread that locks a market for the bond instrument 
or a negative bid-ask spread that crosses a market for the bond 
instrument; and 

receiving, by the electronic trading system, a subsequent trading 
order having a more favorable price than at least one of the orders 
involved in the preventing step, the subsequent trading order 
resulting in a positive bid-ask spread that unlocks or uncrosses the 
market. 

As discussed above, McCausland fails to teach or suggest at least the "preventing" step of claim 

40. See Section La, supra. Also, as discussed above, Lawrence, Lupien and Himmelstein fail to 

remedy the deficiencies of McCausland with respect to at least the "preventing" step and the 

"receiving. . .a subsequent trading order" step of claim 40. See Sections I.c, I.d and I.e, supra. 

Hughes relates to "systems and methods... for supporting the trading of bonds in a 

computerized system using broker dealers as intermediaries." (Hughes at Abstract.) Hughes 

describes the order matching of FIG. 8 as follows: 

The matching process is performed for broker dealers, that is, for 
bids and offers received by a broker dealer. The system performs 
the matching by first generating a list of candidate offers that 
partially match a specific order based on, in one embodiment, 
CUSIP and price, step 240, accounting in price for any markup 
applied by that broker dealer to the specific counterparty submitting 
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each candidate offer. If the list of candidate offers contains only 
one offer, this offer is deemed to match and the system updates the 
order and trade files accordingly to reflect that a trade has 
occurred , step 262. If the offer was subject, the parties are first 
notified and confirmation is requested before the trade is executed, 
as explained above. 

If the candidate list contains multiple orders, one of such orders 
must be selected. In some embodiments, the party that generated 
the original order can specify whether it prefers a match to occur on 
price or on amount of securities in the trade. If the user specified a 
match on price, step 244. the candidate list is searched for one or 
more orders at the best price , step 246. If multiple such orders at 
the best price are found, step 248, the system selects the one of 
such orders having the largest amount of securities, step 250. 
Otherwise, the order at the best price is selected from the list, step 
252. If the user specified a match based upon amount, the 
candidate list is searched for orders at the highest amount , step 
254. If multiple such orders at the highest amount are found, step 
256, the order with the best price is selected, step 258; otherwise, 
the order at the highest amount is selected, step 260. If in either 
instance after narrowing the list based on price and amount the 
candidate list still contains multiple orders, one of the orders is 
selected at random or based on an earlier time of receipt of the 
order. The selected order is used for the transaction, and the order 
files and trade files are updated accordingly to reflect that the 
tr ansaction has occurred , step 262. 

Id. at 15:35 - 16:3 (emphasis added). 

In Hughes: 

The rebroker method populates a SubOrder table that is used for 
order viewing. This table contains the ID of the order, the route 
number, the broker/dealer the order was rebrokered to, and the 
updated price. This table is used for efficient order viewing. When 
viewing an order, the SubOrder table is queried for the customer's 
broker/dealer. The SubOrder table is populated by querying 
CounterPartyOrderSituation and Path tables, described in greater 
detail below. Once a component has been rebrokered the matching 
process is called to detennine if there are two orders that qualify as 
a match. Once a match occurs the route number is used to notify 
all parties involved in the match. This includes the buying and 
selling customer. All intermediaries are notified of any markup or 
commission received on the match. The order is then marked as 
inactive and a record is written to the match table to record the 
matching transaction . 
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Id. at 19:29-44 (emphasis added). 

The Office Action alleges that Hughes discloses "preventing a match under said 
predetermined conditions; wherein said predetermined order conditions preventing a match 
include; wherein a locked or crossed market. . ." {Id. at 24.) 

As set forth above, Hughes teaches that "once a match occurs... [t]he order is marked as 
inactive." (Hughes at 19:39-44.) As the Applicant explained above in Section I.d with respect to 
the locking of orders in Himmelstein, the marking of an order as inactive in Hughes after a 
match occurs is markedly different than preventing a match based on predetermined order 
conditions "resulting in a zero bid-ask spread that locks a market for the bond instrument or a 
negative bid-ask spread that crosses a market for the bond instrument," as claimed by Applicants. 

However, in contrast to Hughes's matching techniques and the interpretation of Hughes 
advanced by the Office Action, Applicants respectfully submit that claims 40, 58, 61 and 71 do 
not recite marking orders as inactive or marking them invalid and sending them back to the broker 
to be fixed. Indeed, Hughes simply does not teach or suggest the step of a match preventing a 
match of orders based on predetermined order conditions "resulting in a zero bid-ask spread that 
locks a market for the bond instrument or a negative bid-ask spread that crosses a market for the 
bond instrument" as recited in claims 40, 58, 61 and 71. 

In addition, Applicants submit that Hughes fails to teach or suggest the step of "receiving, 
by the electronic trading system, a subsequent trading order having a more favorable price than at 
least one of the orders involved in the preventing step, the subsequent trading order resulting in a 
positive bid-ask spread that unlocks or uncrosses the market." 

Therefore, the combination of McCausland, Lawrence, Lupien, Himmelstein and Hughes 
fails to teach, suggest, or render obvious each and every element of claim 40, from which claim 72 
depends, claim 58, from which claim 73 depends, claim 61, from which claims 62-65, 67-69, and 
74 depend, and claim 71, from which claim 75 depends. 

Also, one of ordinary skill in the art could not combine McCausland, Lawrence, Lupien, 
Himmelstein and Hughes to arrive at the steps recited in claims 40, 58, 61 and 71. Therefore, 
Applicants respectfully request reconsideration and withdrawal of this ground of rejection. 
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CONCLUSION 



Applicants' discussion of particular positions of the Office Action does not constitute a 
concession with respect to any positions that are not expressly contested by the Applicants. 
Applicants' emphasis of particular reasons why the claims are patentable does not imply that there 
are not other sufficient reasons why the claims are patentable. 

In view of the foregoing remarks and the inability of the prior art to anticipate, suggest or 
make obvious the subject matter as a whole of the invention disclosed and claimed in this 
application, all the claims are submitted to be in a condition for allowance, and notice thereof is 
respectfully requested. If the Examiner feels that a telephone conference would expedite 
prosecution of this case, the Examiner is invited to call the undersigned. 
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